Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🌱 Remove ginkgo from e2e tests #545

Merged
merged 1 commit into from
Nov 27, 2023

Conversation

tmshort
Copy link
Contributor

@tmshort tmshort commented Nov 16, 2023

Fixes #196

Description

Reviewer Checklist

  • API Go Documentation
  • Tests: Unit Tests (and E2E Tests, if appropriate)
  • Comprehensive Commit Messages
  • Links to related GitHub Issue(s)

@tmshort tmshort requested a review from a team as a code owner November 16, 2023 20:24
Copy link

codecov bot commented Nov 16, 2023

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (d02bca5) 83.72% compared to head (d84e6de) 83.72%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #545   +/-   ##
=======================================
  Coverage   83.72%   83.72%           
=======================================
  Files          20       20           
  Lines         811      811           
=======================================
  Hits          679      679           
  Misses         91       91           
  Partials       41       41           
Flag Coverage Δ
e2e 63.62% <ø> (ø)
unit 78.54% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@tmshort tmshort force-pushed the test-e2e branch 2 times, most recently from ea859a2 to d84e6de Compare November 17, 2023 18:19
Copy link
Member

@stevekuznetsov stevekuznetsov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Just a couple questions

@@ -105,16 +105,16 @@ test: manifests generate fmt vet test-unit test-e2e #HELP Run all tests.
.PHONY: e2e
FOCUS := $(if $(TEST),-v -focus "$(TEST)")
E2E_FLAGS ?= ""
e2e: $(GINKGO) #EXHELP Run the e2e tests.
$(GINKGO) --tags $(GO_BUILD_TAGS) $(E2E_FLAGS) -trace -progress $(FOCUS) test/e2e
e2e: $(SETUP_ENVTEST) #EXHELP Run the e2e tests.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for making this self-contained, nobody has to remember how to use setup-envtest anymore!

Makefile Outdated
e2e: $(GINKGO) #EXHELP Run the e2e tests.
$(GINKGO) --tags $(GO_BUILD_TAGS) $(E2E_FLAGS) -trace -progress $(FOCUS) test/e2e
e2e: $(SETUP_ENVTEST) #EXHELP Run the e2e tests.
eval $$($(SETUP_ENVTEST) use -p env $(ENVTEST_VERSION)) && go test -tags $(GO_BUILD_TAGS) -v $(shell go list ./test/e2e)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any specific reason to use $(shell go list ./test/e2e) instead of ./test/e2e/...?

Copy link
Contributor Author

@tmshort tmshort Nov 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I tried ./test/e2e/... (or maybe it was without the ...?) and it didn't like it, possibly because go test didn't like the syntax (it's been over a week). But there's no reason not to use that vs calling out to the $(shell)

RunSpecs(t, "Operator Framework E2E Suite")
}
t.Parallel()
cfg := ctrl.GetConfigOrDie()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't the ctrl.GetConfigOrDie() helper for in-cluster config when running in a Pod? Why is it in use here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it will also build the configuration from the KUBECONFIG when run outside of a cluster

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And, I believe this E2E is run in a pod, even so, it's working as desired.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As long as you can run it locally that's fine

test/operator-framework-e2e/operator_framework_test.go Outdated Show resolved Hide resolved
ObjectMeta: metav1.ObjectMeta{
Name: "catalog" + rand.String(10),
Name: "plainv0",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not prefer to use GenerateName or random names for parallel runs?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like these names are used in a testing log message to signal we are testing for specific bundle types

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although, I do wonder if it would be more appropriate to create a different testing struct (similar to what we do for table tests) to have the test name that is running be more descriptive. Maybe something along the lines of:

{
  name: "Operator references a plain+v0 bundle"
  operator: &operatorv1alpha1.Operator{...}
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These tests are already run in parallel.
Really no need to use random names when the names are already different, because as @everettraven points out, the name is used as part of the log output.

IF this test were more complicated, I'd go with what @everettraven is suggesting, but there's only two test cases. If this were to increase to 5 or more, then, yes, a more comprehensive table test structure would be appropriate.

@tmshort
Copy link
Contributor Author

tmshort commented Nov 27, 2023

@stevekuznetsov @everettraven updated with all checks passing.


// Get all namespaces
namespaces := corev1.NamespaceList{}
if err := c.List(ctx, &namespaces); err != nil {
GinkgoWriter.Printf("Failed to list namespaces %w", err)
if err := c.List(context.Background(), &namespaces); err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be worth creating a single context to reuse in all these calls instead of using context.Background() in every call?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure it matters much since there will never be a context in test code

Copy link
Contributor

@everettraven everettraven left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes look reasonable to me.

@stevekuznetsov stevekuznetsov added this pull request to the merge queue Nov 27, 2023
Merged via the queue into operator-framework:main with commit 9e5adb0 Nov 27, 2023
12 checks passed
@tmshort tmshort deleted the test-e2e branch November 29, 2023 19:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Update e2e package tests
4 participants